Information systems frequently consist of multiple heterogeneous data sources such as information repositories, financial and human resources systems, customer and sales tracking applications and the like. In this regard, enterprise decision makers often have to relate information from these multiple heterogeneous data sources in order to analyze a business situation and to act upon it. For example, a decision maker might wish to quickly know which of a set of employees not only has a background in aeronautical engineering but also has experience with aeronautical engineering company projects for the purpose of making a staffing decision for an important research and development project. Even with access to a multi-dimensional database of human resources information, a decision-maker may not know how to isolate such a subset of employees. For another example, a decision maker may wish to see a list of distributors that are distributing a particular enterprise product. In this case, with access to merely a database list of distributors and associated products, it may be difficult for a decision-maker to quickly isolate the distributors for a particular product.
Currently, to perform these types of data inquiries to display desired information, most decision support tools are based on a relational, multi-dimensional or similar representation. The analysis of information is performed through query execution with successive visualization of the results. However, this approach requires a deep understanding by the user of the operations that can be applied including an understanding of how data can be filtered and joined and an understanding of how to interpret the visualized results. For example, this type of process might include forming and typing queries with join and filter criteria in order to retrieve data from one or more data sources. This in turn requires a specialist to form the query, who understands the nature of the data source(s) and the nature of the query syntax. With respect to the examples given above, it may be necessary to employ a software engineer that understands database programming languages in order to isolate the list of employees for the aeronautical engineering staffing project or the list of distributors that distribute a particular product.
However, because analysis of business data and making decisions based on such an analysis is becoming more and more of a mainstream task in organizations, it is no longer desirable to restrict the performance of these types of tasks to a class of specialists with the technical skills necessary to perform the queries. Hence, there is a strong need for an easy and flexible way for decision makers to join and filter information from multiple data sources and to visualize the results without having to learn complex tools or query languages.
Computer systems that interact with the user commonly offer a user interface based on multiple windows that can represent applications or data. Windows can be opened, closed, moved, sized, juxtaposed and/or overlapped. Each window represents a region where information can be displayed.
The World Wide Web and hypertext pages have made the browser an important part of a user experience. A browser displays hypertext pages in a window most commonly written in HTML. Pages may include embedded components (regions) such as HTML frames, ActiveX controls, or Java applets, each of which occupy a part of the visible page and are able to display information independently.
Current browser-based user interfaces, such as Microsoft®'s Digital Dashboard, have taken this approach further by defining Web Parts in browser pages (Dashboards) in which information can be streamed independently. The user is able to arrange such Web Parts (regions) in a preferred layout. Essentially, instead of opening multiple instances of a browser, which a user may toggle among for viewing purposes, the Digital Dashboard enables the user to interact with multiple Web parts, browser windows or the like simultaneously as part of a unified user experience.
The user interface paradigms described above and similar approaches are based on defining individual regions on a user screen, each of which can display information. Each region can represent information from a different data source in a different format. FIG. 1A, for example, shows an example of the visualization of data from heterogeneous sources in different regions of a user interface. Region2, labeled “Customer,” displays information from a database with customer related information. In a similar way, Region4, labeled “Geography,” displays information about the geographical regions in which customers may reside. Region1 and Region3, labeled “Sales Cube” and “Sales Chart” respectively, display information coming from a multi-dimensional database. These regions may display information in different textual, multimedia or graphical representations. These regions may also be positioned fixed relative to each other or positioned individually by the user.
Thus, regions represent sets of information that can either be independent of each other or in a pre-computed relationship. In order for the user to easily join and filter information and to influence the relationship of information in the different regions in such a computer system, a user interface mechanism is needed.
One prior art system that addresses this need is U.S. Pat. No. 5,848,424, to Scheinkman et al. (the '424 patent). The '424 patent teaches an improved hypertext navigation system. A browser displays hypertext pages and indicates draggable elements on the page being viewed. The browser also displays drop targets and detects when a user selects a draggable element and drops the draggable element over a drop target. The browser and/or server to which it is connected examine a class relation matrix having entries for intersections of draggable element references and drop target references in which a matrix entry at an intersection of the draggable element and drop target is identified and used for performing an action which is a function of the matrix entry.
FIG. 1B generally illustrates the dragging aspect of the technique of the '424 patent in the context of the multiple data sources of FIG. 1A. In the example, draggable element DE1, labeled “Southern,” can be dragged to drop target DT2, thereby causing the class relation matrix to be examined, and causing only Southern customer names (not shown) to be displayed in drop target zone DT2. However, this prior art technique suffers from a number of failings. For example, once draggable element DE1 is dropped into drop target DT2, it is impossible to tell from the information presented which draggable element(s) have been dropped into any particular drop target, such as DT2. Thus, in the example, it is not apparent from the information presented that DE1 was dropped into DT2, unless the user remembers which draggable element(s) were dragged to which drop target(s). While it might be simple enough to remember the dragging of a single draggable element DE1 to a single drop target DT2, the situation becomes much more complex when multiple draggable element(s) and/or multiple drop target(s) are considered. Thus, the '424 patent does not teach to convey the context of the information being presented, and thus after awhile, a user may no longer fully appreciate the context of the information being presented.
Furthermore, with the system taught by the '424 patent, there is no way to undrag a draggable element DE1 from a drop target DT2, once it has been dropped. While a user may reset the information being presented to its original state, to a time before any draggable elements were dragged, this is wholly inadequate as a solution to the inability to undrag a draggable element, except in the case of a single draggable element. It is wholly inadequate because in the case of multiple draggable elements having been dragged, the user may not undrag each draggable element one by one, for example, to ‘zoom out’ from the specificity of information shown.
Additionally, with the system taught by the '424 patent, there is no way to simultaneously affect all of the regions or drop targets with a single draggable element. To the contrary, only a single drop target may be affected by a dragged draggable element at a time. In other words, to affect all of the drop targets represented by a display, a user would be required to drag a draggable element to all of the drop targets, separately. In the example of FIG. 4B, a user would be required to drag draggable element DE1 to each of DT1, DT2 and DT3 in Region1, Region2 and Region3, respectively, with separate dragging actions in order to affect all of the available information with the draggable element DE1.
Thus, it would be desirable to provide a system in which a user can easily join and filter information, to influence the relationship of information in different regions of a display in a computer system. It would be further desirable to provide a simple and flexible user interface that achieves these goals. It would be still further desirable to provide a user interface mechanism that indicates the context of the information being joined and filtered on display. It would be advantageous to provide a user interface mechanism that allows a user to selectively join and unjoin and filter and unfilter the information being displayed. It would be further advantageous to provide a user interface mechanism that allows a user to simultaneously affect the information being displayed in all of the regions of the display, as opposed to a single region. It would be still further advantageous to provide a user interface mechanism that enables a user to select and/or pin an element contained in the region for the purpose of performing joining and/or filtering operations upon the information contained in the other regions of the display based upon the element selected and/or pinned.